Also, can we point to some specific ways to use scorecard here? I think we want to be careful with what we say can help with something like the xz attack...

"Transparency" is unfortunately an overloaded word in our world. WDYM specifically in this context?

oof, that's a good callout.

I propose that I mean:

• open source
• open build
• open policies
• published "definitions of correctness."

I'd be inclined to remove the sentence all together. Yes, transparency (visibility into the process that creates the software) is one way of increasing trustworthiness but there are other vectors too. "Does this organization have something to lose if they do a bad thing? Do I think that's enough of an incentive for them not to do the bad thing".

Additionally, I don't think "Transparency best-practices" are well defined anywhere (or even vaguely agreed upon...).

Perhaps the easiest way forward is

1. to focus on the submission of bad source (so open builds don't apply here) and assume the other parts of the chain are protected (at the very least they're covered by other threats on this page).
2. to be a bit more hand-wavy since this is a squishy subject:

**Mitigation**: Users must establish some basis to trust the organization they are consuming software from.  That basis may be 1) that the code is open sourced **and** has a sufficiently large user-base that makes it more likely for malicious changes to be detected, 2) that the organization has sufficient incentives (legal, reputational, etc.) to dissuade it from making malicious changes.  Ultimately this is a judgement call with no straightforward answer.

@TomHennen I think SLSA tooling gives you a way to unilaterally improve trust when the source and builds are open source. This is possible independently of whether or not the producer has something to lose.

I agree though that this section needs to be reduced.

I left two suggestions. wdyt @trishankatdatadog @TomHennen ?

Left a comment down there...

good ideas. I'll incorporate these.

I'd be inclined to remove the sentence all together. Yes, transparency (visibility into the process that creates the software) is one way of increasing trustworthiness but there are other vectors too. "Does this organization have something to lose if they do a bad thing? Do I think that's enough of an incentive for them not to do the bad thing".

Additionally, I don't think "Transparency best-practices" are well defined anywhere (or even vaguely agreed upon...).

Perhaps the easiest way forward is

1. to focus on the submission of bad source (so open builds don't apply here) and assume the other parts of the chain are protected (at the very least they're covered by other threats on this page).
2. to be a bit more hand-wavy since this is a squishy subject:

**Mitigation**: Users must establish some basis to trust the organization they are consuming software from.  That basis may be 1) that the code is open sourced **and** has a sufficiently large user-base that makes it more likely for malicious changes to be detected, 2) that the organization has sufficient incentives (legal, reputational, etc.) to dissuade it from making malicious changes.  Ultimately this is a judgement call with no straightforward answer.

@TomHennen what if we update this to cover both:

The mitigation for both is a clearer -- you cannot.

We could redirect from here over to "verifying platforms".

Sorry for late reply. Why do consumers even need to know which producers are trusted to produce artifacts (source code, I imagine, in this case)? Couldn't they just get away with the Source Track VSA from the issuer, and call it a day so long as its subjects/outputs (e.g., source code) matches the inputs to the next step (e.g., build)?

this wording aligns better with the build integrity section below.

I think this is 'fine', but we do lose the introduction of the concept of 'intent' (which we reference later) which isn't quite the same as 'process'. I'd argue the process is one of the ways the producer tries to ensure their intent is tracked, but it's not really what the end user cares about.

I'd also probably argue that the build process is somewhat different and they don't need to mirror each other. To some extent the source is the closest approximation of the org's intent, and then we just rely on the build system to mechanically transform that source faithfully.

I do not think we should use "two trusted persons" as a proxy for producer intent. We should probably say "the documented change process for the source" if we must, but I prefer just "the intent".

added the "objective" section from source-requirements.md, updated the verbs to be future tense.
this is to be the target of future-direction links.

I updated the words to be a little more precise.
In general, I'd expect reviews to be transitive for some situations. but yeah, if your org thinks this is a problem, then this is how you'd fix it.

optional: Robot accounts are discussed below so this seems somewhat redundant. Suggest removing.

That's probably fine. I think these are different threat models, but not sure if the difference is worth calling out, or if these two blurbs are doing so.
This one is about gaining access to two accounts with write and the robots one is about gaining access to an account with bypass.

The mitigation for the first is hard to execute and protect against. You'd have to somehow prevent account takeovers.

The mitigation for the robots one is easier to execute (just run some kind of automation with a poisoned payload, usually) and protect against-- just do not allow any account to bypass code review requirements.

Right. I guess I'll leave it to you?

Optional:

E.g. imagine if the Robot is a GHA that generates code. If the workflow that runs that code is reviewed, and the generation tool is reviewed, then it could be safe?

(commented on the other thread)

I suppose I think there are legitimate use cases for bypassing code review by robots, and I think it is possible to do safely?

I also don't think we have to address that here and now, especially if we don't have a fully fleshed out framework for doing so.

I think this is 'fine', but we do lose the introduction of the concept of 'intent' (which we reference later) which isn't quite the same as 'process'. I'd argue the process is one of the ways the producer tries to ensure their intent is tracked, but it's not really what the end user cares about.

I'd also probably argue that the build process is somewhat different and they don't need to mirror each other. To some extent the source is the closest approximation of the org's intent, and then we just rely on the build system to mechanically transform that source faithfully.